Reviewed; no blockers found.

This nails the functional shape we filed #1609 for — the mcp-custom-resources fixture (docs:///{+path} → a tableless readPage returning { text, mimeType: 'text/markdown' }) is exactly the docs-server case, and the across-segments template read + blob + completions all look right. Thanks for the fast turnaround.

One thing to lock down for that use case, since #1609's premise is a public docs server — i.e. anonymous / unauthenticated clients:

• The code path looks correct for anonymous today: listCustomResources / matchCustomResource are keyed on profile only (no per-user filter), and readCustomResource passes user through and delegates RBAC to the method — parity with mcpTools, which we verified serves anonymous sessions (visibleTo: () => true).
• But all 7 integration tests authenticate (auth = basicAuth(admin.username, admin.password)), so the anonymous path is never exercised. That's the one property our use case actually depends on.
• The registry comment (customResourceRegistry.ts: "listed to every authenticated user on the profile") also reads as if auth is required, which — if the intent is that anonymous works — is worth tightening so operators don't assume a login gate.

Could you confirm anonymous resources/list + resources/read of a custom mcpResource is intended to work, and add one no-auth assertion to custom-resources.test.ts (drop the authorization header, expect the docs:///… read to succeed)? That would guarantee the public-docs scenario the issue is built around, and mirror how mcpTools already behaves.

Confirmed: anonymous resources/list + resources/read of custom mcpResources is intended and structurally guaranteed — listing is keyed on profile only (no per-user filter), and reads pass the (possibly absent) user straight through to the author's method, exactly mirroring mcpTools' visibleTo: () => true posture. effectiveUser in the transport tolerates a userless request, so nothing in the new layer assumes a login.

Addressed in 0a9083e:

• New integration case runs a full no-Authorization-header session (initialize → list → template read) and asserts the docs:///… content serves — on the harness instance the local mapping supplies the user the way a public deployment's anonymous mapping would, so the assertion pins "no auth header required at the MCP layer" end-to-end.
• The registry doc comment no longer says "every authenticated user" — it now names the anonymous public-docs case explicitly so operators don't infer a login gate.

Comment generated by an LLM (Claude Fable 5).

Reviewed via Claude review-queue (full review: harper-1613-0a9083e.md). Solid third leg of the MCP custom-surface triad (mcpResources, after mcpTools/mcpPrompts) — the reserved-scheme guard, RBAC delegation posture, error sanitization, and lazy freshness-rebuild fix are all well done and well tested.

One real gap worth a look: {name} (single-segment) template params don't actually enforce "one path segment" once percent-decoding happens. compileUriTemplate builds {name} as ([^/]+) matched against the raw, still-encoded URI, then decodes the captured group afterward — so a client can encode / as %2F to defeat the segment boundary. Verified locally: docs:///{name} matched against docs:///..%2F..%2Fetc%2Fpasswd passes the regex (no literal /), then decodes to ../../etc/passwd. The module doc and tests explicitly frame {name} as the segment-safe alternative to {+name} — an author trusting that contract for filesystem/resource path construction (e.g. docs:///{id} → fs.readFile(path.join(baseDir, params.id))) would be exposed to directory traversal. Doesn't bite the shipped fixture (readPage does an exact-key dict lookup, and only uses {+path} anyway), so no live exploit here — but the primitive is reusable by any future/customer app.

Suggested fix: validate the raw captured segment has no %2F/%5C before decoding, or split-then-decode per already-delimited segment. At minimum, document the caveat so authors know {name} is a shape hint, not a security boundary.

Great catch — fixed in a49b8b1. compileUriTemplate now records per-param reserved flags, and matchCustomResource rejects any {name} capture whose RAW text contains %2F/%5C (case-insensitive) before decoding — the URI simply fails to match a single-segment slot, so the one-segment contract holds through percent-decoding. {+name} reserved expansion still decodes encoded separators by design. Verified your exact vector: docs:///{name} vs docs:///..%2F..%2Fetc%2Fpasswd no longer matches (unit test added, plus %5C, lowercase %2f, an ordinary %20-in-{name} control, and a {+path} still-decodes control).

Comment generated by an LLM (Claude Fable 5).